Electronic equipment having a built-in computer, such as personal computers, office equipment and household electrical goods have programs which comprise processing such as data processing and equipment control installed, and the programs are executed by the computer. Thus, various types of described processing are realized.
In such programs, static memory regions are allocated beforehand when the programs are designed and dynamic memory regions are appropriately allocated when the programs are executed. Both are used as memory regions that store data. The dynamic memory region is allocated as needed when a program is executed. Consequently, when a dynamically allocated memory region becomes unnecessary (i.e., when it is not used in later processing), then the memory region is deallocated. By configuring the memory regions in this manner, the storage regions of the memory are utilized efficiently.
FIG. 6 is a flowchart describing allocation and deallocation of a dynamic memory region. When a memory region allocation request is issued (step S101), a memory manager allocates a memory region in response to that request and notifies a device control unit of information such as the starting position of that region (step S103). Then, when the processing using the memory region is completed (step S104), a memory region deallocation request is issued, so the memory manager deallocates the memory region in response to that request.
When C, C++ or the like is used as the programming language and programming is performed, allocation and deallocation of the dynamic memory region is explicitly realized by calling a function within the program.
In language processing systems such as Java®, there is a garbage collection feature in the language processing system, so a programmer does not have to consciously deallocate the memory region.
As mentioned above, when a programming language for which it is necessary to explicitly describe allocation and deallocation of a dynamic memory region, such as C, C++ or the like is used and program design is performed, the programmer must always be aware of the fact that a dynamic memory region that has been allocated will be deallocated at any point in time. When the programmer becomes unable to allocate a new memory region in the place where a dynamic memory region existed, the storage region of the memory that is dynamically allocatable becomes reduced. Usually, this is called a memory leak. For this reason, when a program having a memory leak of a memory region continues to be executed in this manner, the memory leak progresses, until the programmer finally becomes unable to newly allocate the dynamic memory region, and execution of the program ends up stopping.
FIG. 7 is a flowchart describing the occurrence of a memory leak. When a memory region allocation request is issued (step S101), the memory manager allocates a memory region in response to that request and notifies the device control unit of information such as the starting position of that region (step S103). When processing using the memory region is completed (step S104), a memory region deallocation request is not issued (step S111), and then thereafter this region is not used, so the total available dynamically allocatable region becomes reduced. When such a memory leak of the memory region repeatedly occurs, the allocatable region finally becomes insufficient. Then, even when a memory region allocation request is issued (step S101), the memory manager fails to allocate the memory region corresponding to that request (step S102a) and notifies the device control unit of an error result (step S103a). Thus, processing is discontinued (step S104a).
In order to prevent beforehand the occurrence of such a memory leak, the programmer tracks the source code and discovers and eliminates the memory leak of the dynamic memory region. However, ordinarily a program includes numerous conditional branches and types of repetitive processing and has a complex internal structure. While trying to discover and eliminate memory leaks, the programmer tracks the source code while considering under what kind of condition will a memory region be dynamically allocated and under what kind of condition will the memory region be deallocated. This work of discovering and eliminating a memory leak of a dynamic memory region is time consuming. Further, because it is necessary for the programmer to verify the source code while considering various matters in this manner, there is the potential for a memory leak of a memory region to be overlooked and to end up remaining within a program.
In the case of a memory leak that progresses relatively early, a memory leak of a memory region that remains can be discovered during testing before a product is shipped, but in the case of a memory leak that progresses relatively late, there is the potential for a memory leak of a memory region that remains undiscovered during testing before the product is shipped.
Further, in order to utilize a garbage collection feature such as mentioned above, memory management is limited to a relatively high-level language. Oftentimes it is difficult to implement a garbage collection feature in a processing system as in the aforementioned C language, and this is not realistic outside of some language processing systems.